Software applications use dates in many operations, from complex financial transactions to the calculation of expiration dates of drivers' licenses and credit cards. Many such applications base their calculations on dates and subtract two-digit year values to arrive at a calculation result. For example, calculations of interest on a 5-year certificate of deposit involve the subtraction of the certificate's issue date from the current date and a determination of interest based upon the difference value. This calculation is not a problem if the certificate matures in 1999, but if it matures in 2001, the same computation can result in an error message or worse. In the year 2000, the two-digit year indication starts over at "00" and unless something distinguishes such date, the year will appear to be the year 1900--or so it will seem to many programs that use only the year's last two digits for dates.
In the early days of data processing, storage space was at a premium and it was decided to use two digits for the year indication. Most programs today carry forward that format and employ two bytes of 8-bit binary data to indicate the last two-decimal values of the year. Many of these programs/applications were written years ago and the authors/programmers who understood their organization and details are no longer available for consultation. Further, calculations employing year fields are often deeply embedded in very large program routines and are thus difficult to find and identify.
The key to identifying year fields in a program, at a reasonable cost, is to do so automatically and avoid the need for programmers to scan the code.
Year fields are normally composites of sub-fields. That is, the fields used to represent "year", "month" and "day" are sub-fields of a larger field of "year". To identify such fields, two scan techniques are currently being used. The first examines the labels assigned to various data fields used by the program. In COBOL, these labels are found in the Data division which is the area of the program which defines each of the data elements used in the program. Using various techniques, key phrases like "year", "yr", etc. are located in the labels. These data fields are then considered to be year-oriented fields. As a further check, the format of each such "year-oriented" field is determined and is scanned to see if it meets one of the commonly used formats for year information. The most common format in use involves three two-digit numbers that are defined consecutively.
The application of this dual test allows a search of a program to be carried out and often leads to the discovery of approximately 80% of the year fields. Because such a search procedure does not consider the interrelationship of a discovered year field with other year fields, both in the same program and in allied programs in the same application, data that would allow a more accurate year field determination is ignored. In co-pending U.S. patent application Ser. No. 08/705,499 filed Aug. 29, 1996 now U.S. Pat. No. 5,794,048, (Attorney docket 835.0003 USU) entitled "Method for Classification of Year-Related Data Fields in a Program", to the Inventor hereof, an improved method is disclosed for identifying year-related fields in a program. The method employs data available in associated fields and thereby assures a higher level of accuracy in the year field identification process. The disclosure of the aforementioned Patent Application is incorporated herein by reference.
The procedure described in the above-noted Patent Application enables identification of year fields with high probability, and thereafter enables each of those year fields to be automatically accessed and to have their year designation revised in such a manner as to enable a removal of the ambiguity which arises from the onset of the year 2000 and forward. A preferred method for revising the year format and for enabling the year conversion procedure is described in U.S. patent application Ser. No. 08/657,657 filed on May 30, 1996 now U.S. Pat. No. 5,758,336 (attorney docket 835.0001 USU) entitled "Date Format and Date Conversion Procedure" to the inventor hereof. The disclosure of the aforementioned patent application is incorporated herein by reference.
Notwithstanding that date fields can be identified and revised to avoid the "Year 2000" problem, once a code listing is revised, it must be tested to assure that the revised year fields produce correct results. However, the testing procedure itself can create a significant computing load if the number of test case combinations is too great. For instance, if a 25,000 line program in COBOL has a 5% date field density (average for COBOL programs), it will have about 250 input date fields. If each combination of variations of possible values for each date field are tested, an enormous number of tests can result (i.e., 10 to the 250th test cases). Obviously, such a computing load is unacceptable.
Accordingly, it is an object of this invention to provide a memory media which enables an improved method of testing a program whose date fields have been revised to avoid the "Year 2000" problem.
It is a further object of the invention to provide a method for testing a program having revised date fields and which imposes a reasonable processing load on the computer used to perform the testing.